A virtual machine (VM) comprises virtualized representations of real hardware, software, and firmware components available in a data processing system. The data processing system can have any number of VMs configured thereon, and utilizing any number of virtualized components therein. The data processing system is also referred to as a computing node, a compute node, a node, or a host.
For example, the host may include a processor component. One virtual representation of the processor can be assigned to one VM, and another virtual representation of the same processor can be assigned to another VM, both VMs executing on the host. Furthermore, the second VM may also have access to a virtual representation of a reserve processor in the host and certain other resources, either exclusively or in a shared manner with the first VM.
Certain data processing systems are configured to process several workloads simultaneously. For example, separate virtual data processing systems, such as separate VMs, configured on a single host data processing system often process separate workloads for different clients or applications.
In large scale data processing environments, such as in a data center, thousands of VMs can be operating on a host at any given time, and hundreds if not thousands of such hosts may be operational in the data center at the time. A virtualized data processing environment such as the described data center is often referred to as a “cloud” that provides computing resources and computing services to several clients on an as-needed basis.
VMs are installed or created on a compute node as needed for processing workloads, meeting service level requirements, and many other reasons. Furthermore, different configurations of VMs may be needed for different purposes. For example, when a VM is created just for providing a user a general purpose computing platform, the VM may be created only with the basic operating system and no applications. In another example, when a new VM has to provide application services, the VM may be created with an operating system and an application server configured thereon. Similarly, many different configurations of VMs may be created for a variety of other purposes.
An image is a binary package that can be installed on a hardware to instantiate a VM on the hardware. A layer is a software package that participates in an image. An image can include any number of software packages, whose layers are assembled together in the image as a monolithic binary. A single image can, but need not necessarily, represent an application.
A commonly used method of virtualization—traditional virtualization—preconfigures various VM configurations as template images (templates). When a VM having a specific predetermined configuration has to be created on a compute node, a suitable template is selected from a template storage, such as a database or a file-system, and installed on the compute node to create a VM having the desired configuration. An image of a VM in traditional virtualization is a monolithic binary image.
Another method for virtualization is container-based virtualization. Container-based virtualization, also called operating system virtualization, is an approach to virtualization in which the virtualization layer runs as an application within the operating system. In this approach, the operating system's kernel runs on the hardware node with several isolated application environments installed on top of it. The isolated guest application environments are called containers. In other words, a container is a running instance of an image of a VM in which the layers are distinguishable from one another.
Container-based virtualization is a way to operate several VMs on the same host, where the VMs share the same kernel and memory space among themselves and with the host. The isolation between the containers occurs at multiple resources, such as at the file-system, the network stack subsystem, and one or more namespaces, but not limited thereto. By sharing the same running kernel and memory space there is virtually no difference between the performance of the “host” operating system and the containers.
This method of virtualization is significantly different from the traditional virtualization technology where the hardware is emulated using a software emulation layer, which causes provisioning latencies, slow startup times, and decreased performance of the underlying hardware. These and other drawbacks of the traditional virtualization method are due to the software emulation layer that sits between the physical hardware of the host and the operating system that is being run on top of the emulated hardware.
Generally, a container is an image formed using a set of one or more layers. For example, a container may include one layer for modifying the operating system to a specific version or specific customization—e.g., apply Ubuntu™ 14.04 binary to the underlying Linux® operating system (Ubuntu is a trademark of Canonical Ltd. in the United States and in other countries. Linux is a trademark of Linus Torvalds in the United States and other countries); another layer might include configuration data for the operating system customization—e.g., Ubuntu configuration; another layer might apply or remove updates to the modified operating system—e.g., apply Ubuntu system updates; another layer might include an application to be configured in the container—e.g., the binaries of an application server; another layer might include the configuration data of the application server; another layer might include the binary or other data of a user application that is to be executed using the container; another layer might include a set of environment variables that is needed to successfully operate the application server, the user application, or both on the container; and so on. Many different types of layers can be similarly configured in a container image, and any number of layers can be configured in a container image to create a container.
The container-based virtualization technology offers higher performance and less resource footprint when compared to traditional virtualization, and has become an attractive way for cloud vendors to achieve higher density in the datacenter. Thus, containerization (i.e., operating a virtualized data processing environment using container-based virtualization) is changing how workloads are being provisioned on cloud infrastructure.
Containers offer many advantages, but the illustrative embodiments recognize that significant hurdles exist in making container-based virtualization technology prepared to handle enterprise-type workloads. One such hurdle is around image management and initial provisioning time latency. Due to the layered nature of container images, traditional approaches to image management and workload placement are insufficient to optimize container-based workloads.
Provisioning is the process of providing a resource to a configuration. Specifically, in deploying containers on host machines in a data processing environment, provisioning a container refers to the process of providing the container image—i.e., providing the layers comprising the container image—over a data network from a repository of layers or images to a selected host machine in the data processing environment where the container is to be created and operated.
When containers are provisioned in a data processing environment where traditional placement techniques are used for the provisioning, under certain circumstances, container provisioning can experience latency that is excessive, e.g., higher than the expected latency of a preset performance metric, due to on-demand download of container layers. The illustrative embodiments overcome this and other drawbacks of provisioning containerized images in a data processing environment.
In the above example of Ubuntu, application server, and user application layers, the aggregation of those layers makes up the container image. When the container image is built, each build time action generates a new layer which leverages functionality from the layers beneath. Each layer is assigned a unique identifier at build time. When request is made for a container to be started on a given host, the host verifies that each layer's unique identifier is present on local storage before the host completes the request. If a particular layer identifier is not present, that layer is downloaded from a source location prior to starting the container.
A layer can be large and the downloading of the layer can result in slow provisioning time and high latency depending on network conditions. The illustrative embodiments recognize that generally, a significant part of the start-up latency in container-based virtualization is due to the downloading of layers, and particularly the larger-than-a-threshold-size layers. Presently available methods determine the layers that are missing from a local cache of a host and download only those layers that are missing in the local cache. The illustrative embodiments recognize that issues still exist, and cause unacceptable start-up latency when the largest layer, or layers exceeding a certain threshold size, are not present in the local cache. The illustrative embodiments minimize or reduce the download latency—particularly when one or more layers exceeding a certain threshold size have to be downloaded, thereby improving the provisioning and deployment efficiency of containers in a data processing environment.